-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: remove default manualChunks strategy in core, adds split vendor plugin package #6681
Conversation
Co-authored-by: Ben McCann <322311+benmccann@users.noreply.github.com>
Co-authored-by: ygj6 <7699524+ygj6@users.noreply.github.com>
Mh... my personal note would just be tto move this into it's own repo in the vitejs org |
I think it is the other way around, or at least the same. If the project is in the vitejs org it is also the same set of maintainers. That being said, I don't have an issue with moving it out, but the reason shouldn't be to increase maintainability. |
I prefer keeping it inside the core.
|
Edit: corrected my comment here, I thought that soda's comment was in the other PR 🤦🏼 @sodatea so you consider that we should merge #6534 instead of this PR and that the API as defined here is good enough to enable users to continue using the vite <2.7 scheme? I'm fine with that. The idea to move it out of core was to be able to merge it without committing to an API, but we can always deprecate if we ever came up with more general chunking options. And I didn't want to move it out of the monorepo because of the maintenance burden... that this PR increases anyways so I'm not happy with it either If this is the case, would you approve #6534? |
I mean I think #6534 is a good short-term solution for now. So I've approved that one. |
My vote also goes towards #6534 |
Closing this one, we are going to move forward with #6534 |
Description
Alternative to #6534 with the
splitVendorPlugin
andsplitVendor
manualChunk strategy function out of Vite core. This PR creates a new package@vitejs/plugin-split-vendor
in the monorepo. The plugin is very simple so it uses the same unbundled approach from plugin-vue-jsxAdditional context
Another option is to take this plugin out of the monorepo, or even in a personal account. But I think having it in the monorepo is good enough, we avoid adding a new API to core but it is still discoverable
What is the purpose of this pull request?